Skunkware 5/Skunkware 5.iso/src/Games/reve/TODO

Text File | 1995-05-03 | 18.2 KB | 378 lines

/*  @(#)TODO 1.26 91/11/13
 *
 *  Copyright (C) 1990, 1991 - Rich Burridge & Yves Gallot.
 *  All rights reserved.
 *
 *  Permission is granted to copy this source, for redistribution
 *  in source form only, provided the news headers in "substantially
 *  unaltered format" are retained, the introductory messages are not
 *  removed, and no monies are exchanged.
 *
 *  Permission is also granted to copy this source, without the
 *  news headers, for the purposes of making an executable copy by
 *  means of compilation, provided that such copy will not be used
 *  for the purposes of competition in any othello tournaments, without
 *  prior permission from the authors.
 *
 *  No responsibility is taken for any errors on inaccuracies inherent
 *  either to the comments or the code of this program, but if reported
 *  (see README file), then an attempt will be made to fix them.
 */

Known problems.
===============

*  From Nick Sayer <[e-mail]>
   System is a Sun 2/170 running SunOS 4.0, using the TTY version on a
   TVI-925. Reve makes a mess on so called "magic-cookie" terminals.

*  With the X11 version, if you are dragging the mouse as the computer is
   placing it's piece, and "Animate Move" is set on, then bogus pieces are
   displayed.

*  Allow the computer to play itself. Currently this option is disabled,
   because of the inability with some of the graphics versions to interrupt
   it, once it's started.

*  There are several problems outstanding with the XView version:
   ~ **IMPORTANT** It's still possible to hang the server, if the left
                   mouse button is clicked at the wrong time.
   ~ The hourglass cursor should be drawn in XOR mode.
   ~ The game board isn't correctly painted with the -m command line option.
   ~ It should be possible to start a load/save by just typing Return in the
     Load/Save popup.
   ~ Need to add XV_HELP_DATA attributes to each item, and create a reve.info
     file with help information.
   ~ The initial position of the reve window is coming up randomly. If it's
     position isn't given on the command line, it should start at (0,0).
   ~ The control panel should come up immediately under the game board.
   ~ The position_popup() routine needs to make sure that popups are always
     fully displayed on the screen.

*  Need to add in the ability to show the last move, and show all moves to
   the tty version.

*  From [e-mail]
   With the tty version, sometimes, at the beginning of the game, reve will
   ignore my keystrokes for my first move, i.e., typing "d3" won't generate
   a "Move:d3" message and the program just sits there.

*  From Robert Cohen <[e-mail]>
   It would be nice if the help and props windows vanished when you iconise
   the main window.

*  From Tom Friedel <[e-mail]>
   When I use reve on a 16 bit display there are three lines for the icon.
   On 8 and 4 bit displays I have a few circles for the icon. The icon code
   appears to be hard-wired for mono or 8bit screen; it should use something
   like XGetImage instead.

*  From Richard K. Lloyd <[e-mail]>
   Inside the Props window, the bottom-left pixel and the one above it
   belonging to the checkboxes is WHITE rather than black on a mono display.
   In other words, the checkboxes look 'open' in the bottom-left corner. The
   checkboxes are, surprisingly, OK on colour displays though.

*  From Richard K. Lloyd <[e-mail]>
   When running twm, both the Props and Help window cannot be properly
   iconified by clicking on the twm iconify widget present in the window's
   title bar. The windows *do* iconify, but then immediately de-iconify
   themselves back to normal again! The main board window seems to iconify OK
   though.

*  From Robert Cohen <[e-mail]>
   If you set a search depth then go back to a difficulty it doesn't seem to
   reset max_depth to 2.

*  From Robert Cohen <[e-mail]>
   There's a couple of funnies about the behaviour of the amount of computer
   time left when you change level or undo moves. Changing levels doesnt
   affect the record of time left in the undo list so if you make a move at
   a low level, change to a high level, make a move and then undo, it thinks
   you have very little time left even though you are on a high level.
   Also changing levels resets the computer time to the entire quota for
   that level. Surely it should be relative to how far you are thru the game
   eg. half way thru the game gets 1/2 of the quota for that level.

*  From Valerie Haecky <[e-mail]>
   When entering a game using two human players, there is no way of making
   one of them pass. I tried to switch to computer mode for one move, and
   let the computer pass, but when I switch back to all human, reve dies
   spectacularly.

*  From Richard K. Lloyd <[e-mail]>
   With the recent resizing of the board in reve v1.2, I'm getting the
   "dotted line" problem as the outline around white pieces. This is with
   the X11 (Xlib) version on a mono screen, under HP-UX v7.0.

*  From Richard K. Lloyd <[e-mail]>
   The Imakefile compilation doesn't quite conform to normal
   "standards". The "reve_proc" program should compiled with
   a straightforward "make x11" command, but it doesn't actually
   end up getting compiled until you do a "make install" !

*  From Michael Glad <[e-mail]>
   If you use the 'undo' button, reve gets confused. If running at level 5,
   the effective level drops to an estimated 2.


Suggested enhancements.
=======================

*  From Richard K. Lloyd <[e-mail]>
   Supply a way of forcing the computer to move before its search is complete.
   This would be very handy at the higher levels.

   If we can actually see what moves have been though about so far, then you
   may no longer be left in the dark as to what the computer is doing (you can
   manually stop it thinking when it finds a really strong move for example).
   As an afterthought, I realised that it would be nice to know what ply
   level the search is currently up to.

   An even neater trick would be to number each square with its position in
   the best move list. You could either show this at the end of each ply or
   update in real-time (in which case, the numbered squares would need to be
   cleared when the ply search is deepened to avoid confusion - also some
   on-screen renumbering would have to be done on-the-fly).

*  From Richard K. Lloyd <[e-mail]>
   "New Game" should just undo the game right back to the start. That way
   a player can use the move forwards facility to replay the game easily
   right from the start. Of course, as soon as the player makes a new move,
   then s/he won't be able to replay the game any further.

*  From Richard K. Lloyd <[e-mail]>
   Countdown clocks for blitz games (first to hit 00:00:00 loses if the game
   is still in progress).

*  From Richard K. Lloyd <[e-mail]>
   From Valerie Haecky <[e-mail]>
   Board editing. A 'setup' mode, where you can place stones on the board
   (NOT moves). This is good for game analysis, puzzles, starting from a
   specific opening (like Reve always plays perpendicular, and no-one knows
   whether this is best, and it would be nice to set up other openings).
   It has to be stones, not moves, because puzzles don't always contain legal
   positions, and transcripts have bugs.

*  From Richard K. Lloyd <[e-mail]>
   A 'I will win/lose in x moves' announcement if a forced win/loss is
   detected.

*  From Richard K. Lloyd <[e-mail]>
   When you click on Quit and have actually made some moves/changes, then
   it would be nice to have a dialogue box pop up to say "Save game before
   Quitting ?" with Yes, No and Cancel buttons in the box. Perhaps this could
   be part of a .reverc/.Xresources setting, because some people might not
   like the intrusion. This should probably apply to the "New Game" button
   too come to think of it ("Save game before Restarting ?" in this case).

*  From Richard K. Lloyd <[e-mail]>
   Display the number of board positions searched so far. The frequency of
   update is up to taste really - perhaps when the best move found is
   updated. Tied in with this, you could give a "positions searched per
   second" rating when the computer finishes its search and makes its move.
   This would be a great measure of the speed of the machine/algorithm.

*  From Richard K. Lloyd <[e-mail]>
   Allow the level to be explicitly set in seconds per move (or perhaps
   minutes per game as it currently is) rather than having a fixed set of
   levels. The highest playing level could be called "Infinite" rather than
   "Tournament" and just plays until interrupted or the game end is detected.

*  From Richard K. Lloyd <[e-mail]>
   Implement an "Equality" play mode which matches the computer playing time
   exactly with the human's.

*  From Richard K. Lloyd <[e-mail]>
   Have a 3-D board option. It'd sure look great. You just need to angle the
   edges inward from bottom to top and draw elipses rather than circles.
   Taking this further, you come show a wood grained board, and a light
   source up above for ray shaded stones.

*  From Richard K. Lloyd <[e-mail]>
   If you intend to implement on-screen clocks (hopefully in HH:MM:SS
   format), then have options to reset them to zero at any time and also
   to stop them (effectively a "Pause" mode) - perhaps that could be tied
   in with iconification. Perhaps another option (or resource) to decide
   whether the clocks should be analog or digital.

*  From Richard K. Lloyd <[e-mail]>
   Show the four "blobs" at the edges of the four central squares (top-left
   of d4, top-right of d5, bottom-left of e4 and bottom-right of e5). No,
   I don't know why they're there on commercial Othello boards in the first
   place, except perhaps to mark the starting positions.

*  From Richard K. Lloyd <[e-mail]>
   Have some annoyingly intrusive comments during the game :-) Examples
   could be: "That was a really bad move", "I'm crushing you", "This
   position is boring", "Hurry up and make your move !" etc. etc.

   [Othello2, the predecesor of the graphics used in Reve, and posted to
    comp.sources.games last year, used to have this ability - Rich.]

*  Try to get online copies of the two paper referenced in the README file.
   Otherwise, add more comments to the computer strategy code.

*  From Richard K. Lloyd <[e-mail]>
   Allow the board to be rotated 90 degrees. The movelist will also have
   to be adjusted of course.

   [Board rotation is only necessary, if we also support a printing
    facility fro transcripts. For publishing games usually start
    on c4. Also, if we want an opening library composed from
    played games, or other learning mechanisms, we would have to
    normalize the board. For a playing tool, this is not necessary - vmh.]

*  From Soren Hein <[e-mail]>
   Possible to give some strength indication of the levels? Maybe by
   analogy with chess ratings, if you're familiar enough with Elo-ratings
   to make guesses/comparisons.

*  From Soren Hein <[e-mail]>
   There should be symmetry between the case when the human can't move
   and when there is only one move for them. Yet in one case the program just
   goes on, and in the other, it waits for the only move. I would like to
   give my OK to forfeit before the program takes its next move.

*  From Dan Bernstein <[e-mail]>
   An idea which can possibly be incorporated:

   Along with each board keep two arrays size 100 (it's easier on the code
   to use artifical borders) of bytes. Each byte has a bit set if a player
   can take from that spot in the direction numbered by the bit. This turns
   out to be reasonably easy to maintain with the moves, and it makes legal
   move checks and actual flips so fast that the program runs about three
   times faster overall.

*  From Richard K. Lloyd <[e-mail]>
   Add in a move list window, which would contain a scrollable list of all
   the moves so far (plus evaluation for the computers moves).

*  From: [e-mail] (Robert Cohen)
   In order to guage which of the machines you have available perform best as
   Reve servers, or to choose between different compilers or to choose which
   compiler switches to use, it would be useful to have a measure of how fast
   Reve runs. You could have a switch that makes reve evaluate a particular
   preset position to some set depth and then tells you how many positions a
   second it checked. You could call this a rhevestone :-).

   Also by checking the answer it got against what it was supposed to get,
   you would have a simple regression test for checking for compiler bugs
   on new architectures.

*  From: [e-mail] (Robert Cohen)
   A cute feature I noticed in the standard X11r4 othello is that it thinks
   during the humans move time. If the person is a slow player this could make
   an appreciable difference if only in giving reve quicker responses.

   From [e-mail] (Soren Hein)
   Is there any way the computer could utilize the opponent's time too?
   (This would probably require major recoding. Something like first
   guessing at the opponent's move using a shallow search, and then using
   a shallow search to order the possible responses to aid the alpha-beta
   search to deeper levels, once it becomes the computer's move again.)

*  From: [e-mail] (Robert Cohen)
   It would be nice to add a bit of variety to reve's play. This could be
   done in a variety of ways. A simple approach would be to add some minor
   randomness to the evaluation function (optionally of course).
   A more sophisticated approach would be to allow the user to tailor the
   evaluation function. This could be either done as a fixed set of play styles
   eg aggressive, cautious, unpredictable etc or by allowing the user to
   change some numerical constants eg the weighting put on mobility by slider.
   Of course there would be a "tournament" setting to make reve play as well as
   possible.

*  From Michael Glad <[e-mail]>
   Perhaps there should be a facility a'la SUN's chesstool to use the
   interface of reve along with other othello programs. This would make it
   easier to let them compete with each other.

*  From Robert Cohen <[e-mail]>
   A more general debugging system where there is a debugging print call you
   can make that has a detail parameter indicating how "detailed" this message
   is.  Then there would be a debugging window that by default would only
   display the least detailed information eg a list of moves made but you
   could set it to display the level of detail you wanted. Also you can get
   the debugging information of a potentially different detail level stored
   in a file. This would replace the current logging stuff.

*  From Thomas K. Bischoff <[e-mail]>
   Notes for improving the notation used by load/save game.

   The 'save game' file format is to verbose. You don't need two columns.
    1,  <f-5>  [ note : 0 ]
    2,  <d-6>  [ note : 0 ]
    3,  <c-4>  [ note : 0 ]
    4,   -     [ note : 60 ]
    5,  <c-5>  [ note : 60 ]

   The standard notation for humans goes like this:
        +--+--+--+--+--+--+--+--+
        |55|42|41|40|36|34|54|53|
        +--+--+--+--+--+--+--+--+
        |58|57|43|39|35|13|52|19|
        +--+--+--+--+--+--+--+--+
        |47|46| 3| 4|11| 8|14|12|
        +--+--+--+--+--+--+--+--+
        |44|48| 5| W| B| 6| 9|16|
        +--+--+--+--+--+--+--+--+
        |49|33|22| B| W| 1|10|15|
        +--+--+--+--+--+--+--+--+
        |28|25|21| 2|30| 7|20|17|
        +--+--+--+--+--+--+--+--+
        |51|45|26|23|24|18|50|29|
        +--+--+--+--+--+--+--+--+
        |56|38|27|37|31|32|60|59|
        +--+--+--+--+--+--+--+--+

   In this notation the passes don't get a move number, so there are at
   most 60 moves.

   But in the text you see also a more chess like notation :
   55.a1 b2; 57.a3 pass; 59.a7 b7; 61.a8

   Add more info to the 'save game' file format. Like who played, what
   time limit/level, time left etc. This is important to get the computer
   playing at the correct level, and to use the correct amount of time
   left.

*  From Thomas K. Bischoff <[e-mail]>
   Make the computer player chooseable for both sides(black and white). This
   would allow to test different computer algorithm against each other.
   This could be done by choosing a name in the prop panel, which is the name
   of the program which gets forked.


Items we're unlikely to implement.
==================================

*  From Richard K. Lloyd <[e-mail]>
   From Soren Hein <[e-mail]>
   What about a 'Play Next Best' option? This would undo the last computer
   move and play the second best move found rather than the best one. If
   selected again, there would be another undo and the third best move would
   be made instead and so on, until the move list is exhausted. It's great
   for trying out different moves in the same position.

   [There is currently no ordering move list, because a search can be stopped
    by the alarm. Then the move list is only 1 or 2 moves length - Yves.]

*  From Richard K. Lloyd <[e-mail]>
   A display of the full tree for the best move rather than just the best
   move itself.

   [In my algorithm, it is impossible to have it. How do want to know, when
    you are in the tree, that it will be the best move ? And when you know it,
    it is impossible to know where you were in the tree - Yves.]

*  From Richard K. Lloyd <[e-mail]>
   A resign feature if the search shows a completely lost endgame.

   [Othello is not chess. The result is the disks differential, not win,
    tie or loss. And I don't know if it is a "completely lost endgame". I
    only know that if the opponent is perfect, then I will lose. A human
    player that should win at move 46 and doesn't use undo, can very easily
    lose - Yves.]